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ABSTRACT 


One of the latest network architectures is the Software Defined Network (SDN) in which the data and control planes are segregated. This keeps apart, the two important 
components the packet forwarding and the switches that act as packet carrying devices. The control of forwarding the packet is performed by a programmable software 
component, the controller, and the forwarding elements such as switches are regulated by the controller. This architecture also provides open interfaces for 
communication between the controller and the forwarding hardware as well as the controller and network applications. Among a few protocols that exist which 
provide open interfaces for communication among the controller and forwarding element, OpenFlow (OF) is regarded as a standardized protocol in this architecture. 
The controller programs the data plane through these open interfaces, whereas, the open interfaces for communication among the controller and the applications allow 
easy development of network applications. By providing eminence benefits over traditional network architecture in the recent years SDN is one of the important areas 
ofresearch. Therefore, in this paper, we have highlighted the major functioning of SDN. 
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INTRODUCTION: 

Traditional networks require a number of different protocols to specify a stan- 
dard in order to meet their technical as well as industrial needs [1, 2]. Such net- 
works are complex [1, 3, 4, 5], vulnerable and static [5, 6], as a result, these net- 
works cannot accommodate changing traffic, have inconsistent policies [7, 8], 
are difficult to manage, unable to scale, vendor dependent [9, 10, 11, 12, 13, 14] 
where innovations are almost impossible. Above all, traditional network man- 
agement requires the manual configuration of each network device [7, 14]. All 
these drawbacks of traditional networks call for Software Defined Network 
(SDN) architecture and its associated standards [2, 6, 7, 14]. 


In traditional networks, the network control, as well as the data plane, lay on the 
same forwarding element [8, 9, 10]. In Software Defined Network (SDN) archi- 
tecture, network control is separated from the data plane [8, 11, 12, 13]. The net- 
work control in SDN is taken out from the forwarding element and is embedded 
as software-based logically centralized control known as the controller [6, 8]. 
This architecture provides open interfaces for communication among the con- 
troller and the forwarding element [15] and these may be any of the vendor- 
independent Application Programming Interfaces (APIs) such as ForCES (For- 
warding & Control Element Separation) developed by the Internet Engineering 
Task Force (IEFT), OpenFlow (OF) developed by ONF (Open Networking Foun- 
dation) or any other proprietary protocol [11]. These open interfaces allow the 
controller to install rules in the forwarding element and accordingly the network 
traffic moves [15]. SDN also provides Open interfaces for communication 
between the controller and the applications thereby allowing the development of 
distinct custom-built applications for network management. As a result, new net- 
work capabilities and services may be easily developed as well as deployed in 
SDN [7, 9]. 


Section II of the paper introduces the basic concepts of SDN architecture, and the 
subsequent section III presents a brief on OpenFlow protocol, section IV the con- 
trol plane, and section V the forwarding elements. The last section VI discusses 
the conclusion. 


Software Defined Networks: 

In Software Defined Network architecture, the network control is detached from 
the data plane [8, 11, 12, 13]. The data plane is developed from special purpose 
hardware and is only used to forward network traffic [10] whereas the control 
plane resides in network servers as a logically centralized control program that 
installs rules in the forwarding element [6, 10, 12]. Traffic in the network is 
directed in accordance with these rules [1]. While routing, path computation, sig- 
naling, etc. are the most common control plane functions, the addition of new fea- 
tures such as virtual private network (VPN), cloud computing, contents distribu- 
tion networking, fault tolerance, mobility, etc. have resulted in the complexity of 
the control plane [16]. 


SDN can conceptually be represented as three-tier architecture as shown in 
Fig.1. 


Infrastructure Layer (Tier-1): Comprises all the forwarding elements and 
includes software interfaces and hardware components in the forwarding ele- 
ments. 


Control Layer (Tier-2): The control layer regulates and manages forwarding hard- 
ware i.e. Tier-1 and consists ofa software-based logically centralized controller. 
Application Layer (Tier-3): This layer consists of applications and services that 
make use of the control and infrastructure layer, i.e. Tier-1 and Tier-2. The Open 
Application Programming Interfaces (APIs) for communication between the con- 
troller and applications enable the easy creation of a custom-built network appli- 
cations [12]. These applications perform all network management tasks and the 
traffic in the network is moved as per the requirements of these applications [17, 


18]. 
Application Layer 


Infrastructure Layer 


Fig. 1: Software Defined Network: A three-tier architecture 


Among many available protocols, OpenFlow (OF) is generally regarded as a de- 
facto standard for SDNs [10, 13]. 


OpenFlow (OF): 

OpenFlow architecture separates the control and data planes which are then tied 
by OpenFlow protocol by providing standard interfaces for communication 
between them [6]. OpenFlow (OF) is an open-source routing southbound proto- 
col for communication between the control and the data plane. By providing a 
standard programmable interface, OpenFlow permits the programmers to 
directly control the data plane by providing rules (flows to route packets/flow in 
the network [6, 10, 12]. Many algorithms for traffic engineering, server load- 
balancing, data center routing, energy-efficient network management, 
virtualization, fine-grained access control, traffic monitoring, fault tolerance, 
denial of service detection, host mobility, etc. using OpenFlow have already been 
developed by researchers [10], [19]. 


OpenFlow is a flow-oriented technology and most of the OpenFlow applications 
send data as flows instead of new functions in switches. DIFANE is a distributed 
flow management architecture that deals with the traffic in the data plane. In 
DIFANE, the wildcard rules are distributed among commodity switches, and 
packets are only forwarded through switches that have necessary rules. There- 
fore, DIFANE may quickly react to network changes. DevoFlow, scalable archi- 
tecture is built to overcome the drawbacks of OpenFlow for high-performance 
networks. It decreases switch-controller interactions by maintaining a reason- 
able amount of visibility, thus, simplifying the design of high-performance 
OpenFlow switches. 


Copyright© 2022, IERJ. This open-access article is published under the terms of the Creative Commons Attribution-NonCommercial 4.0 International License which permits Share (copy and redistribute the material in any 
medium or format) and Adapt (remix, transform, and build upon the material) under the Attribution-NonCommercial terms. 


International Education & Research Journal [IERJ] 


Research Paper 


OpenFlow specifies a flow as a set of header fields, counters, and associated 
actions. The methodology behind OpenFlow is that the controller first composes 
network flow rule logic and then specifies the rules in the flow table of one or 
more OpenFlow-enabled switches dynamically. The flow table already contains 
a set of flow rules. The incoming packets are matched with these flow rules and 
accordingly specified action to process the flows in the data plane takes place 
{12, 18]. 


Initially, OpenFlow was designed at Stanford University in 2008 [22]. Different 
versions of the OpenFlow protocol specifications are 1.0.0, 1.1.0, 1.2, 1.3.0, etc. 
have been developed. 1.0.0, is the widely deployed OF specification. OpenFlow 
was initially developed for research fields but, presently it is also being used in 
commercial applications such as data centers [23]. Using OpenFlow for com- 
mercial applications raises new challenges such as performance and scalability. 
In order to provide developers/researchers a clue that how OpenFlow architec- 
ture will perform on certain parameters, using a simulation basic model for the 
forwarding speed and blocking probability ofan OF switch with an OF controller 
is derived that depends on the measurements of switching times of current 
OpenFlow hardware [23]. 


One of the important parameters in network management is the measurement of 
network traffic. Time, as well as accurate measurements, are the two important 
factors on which network traffic depends. Existing solutions for network mea- 
surement such as the use of custom-built hardware or data collection and analy- 
sis, are unsuitable because of high overheads. A more accurate, low overhead 
practical traffic measurement framework is suggested that runs on commodity 
hardware. In this, the switches match packets against a small collection of rules 
and update traffic counters for the highest-priority match. A separate controller is 
used to read the counters which also dynamically adjust the rules and within no 
time send them to switches on identifying large traffic aggregates. In the initial 
step towards the development of this framework, a hierarchical heavy hitters 
(HHH) algorithm is designed and evaluated. This is used to identify large traffic 
aggregates and to keep the balance between measurement accuracy and switch 
overhead [24]. 


There are two methods of communication between the switch and the controller. 
One is the out-of-band method in which network paths (such as VLANs or sepa- 
rate physical interfaces) that are not affected by OpenF low operation are required 
for communication between the two. The other is the in-band control method 
where the OpenFlow network is used for data transfer as well as communication. 
The rules are also created in two ways in the OpenFlow networks: proactive and 
reactive. In proactive style, rules are inserted in switches before they are needed. 
In reactive style, rules are inserted into switches according to the packets 
observed by the controller via Packet-In messages. In these networks, when a 
packet does not match a rule, switches generate a Packet-In message. Such a 
packet is sent to the controller and the controller takes the appropriate decision to 
handle the packet. 


In 2011, a group of approximately 70 members including researchers, network 
administrators, network operators, and vendors formed the Open Networking 
Foundation (ONF) to make OpenFlow the new standard for SDN networks [8, 
10, 18]. 


Controller: 

The main logic behind SDNs is that all the switches and the routers move deci- 
sion-making power to the logically centralized controller which is regarded as a 
network operating system and enables all control and management-related func- 
tions [1]. 


Aset of open APIs allows communication between the controller and switches as 
well as controller and applications. The interfaces used to communicate between 
different layers of the SDN stack, as per their functions in SDN architecture, are 
categorized as: 


¢ Northbound APIs: To communicate between controllers and applica- 
tions [12, 17]. 


¢ Southbound APIs: To communicate between the controller and the 
underlying hardware. 


* East/Westbound APIs: To communicate between groups of controllers 
for state synchronization [17]. 


In SDNs, network virtualization performs a significant function. It may be easily 
implemented in SDN because both the controller applications and switch for- 
warding tables use APIs. Thus, network virtualization may be added as an exten- 
sion to the OpenFlow controller. Network virtualization with SDN provides bene- 
fits of dynamic resource allocation and also allows each “tenant” with its own net- 
work topology and traffic control [23]. 


Forwarding Elements: 

The forwarding elements are switches, routers, and access points which are used 
to carry network traffic [2, 13]. No special-purpose device or any proprietary 
hardware is required in an OpenFlow network. Therefore, the devices used can 
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be grouped as dedicated OpenFlow switches, and routers in which traditional 
Layer 2, and Layer 3 processing (forwarding and routing) are not required. The 
other type is OpenFlow-enabled general-purpose Ethernet switches, and routers 
to which Open-Flow protocol and interfaces as new attributes are added. In such 
devices, Ternary Content Addressable Memory (TCAM) is used to build a flow 
table. 


The data plane of an OpenFlow switch is made programmable by dynamically 
specifying the rules in a Flow Table of the switch that is logically created by the 
OpenFlow controller [12]. As aresult, flows are routed depending on flow entries 
in the flow table of switches as displayed in Fig 2. 
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Fig. 2: OpenFlow Architecture for communication between Controller 
and Switch [23, 25] 


Flow Table, OpenFlow protocol, and secure channel are three main components 
ofa switch. Flow Table: It contains a list of flow entries where the incoming pack- 
ets are compared with the flow entries. Each flow entry contains (i) a packet 
header, (ii) action, and (iii) statistics. Packet Header defines the flow rules. 
Incoming packets are compared with the header field of each flow entry and if 
matched, the packets are processed as per the action specified in that entry. For 
retaining the flow statistics Counters are used [9]. Therefore, as a packet comes, a 
highest-priority matching rule is selected by the switch, counters are updated, 
and the specified action is executed. In case no rule is matched, the switch sends 
the packet header to the controller and waits for a response from the controller. 


The OpenFlow Protocol: It provides interfaces that allow the controller to 
change flow rules in the flow table of a switch [23, 25]. In this way, the rules are 
specified in the switches as per the authorization of the programmable central- 
ized controller. Consequently, this enables us to list countless benefits of SDN. 


CONCLUSION: 

The main reasons for Software Defined Network architecture to gain importance 
are: (a) separation of control planes and (b) logically centralized software control 
program that is taken out from the network and provides a global network view 
have resulted in a marked difference between SDN and traditional network and 
thereby increases the importance of SDN. 


As aresult, the controller abstracts the underneath forwarding hardware from net- 
work applications and this ultimately culminates in a number of benefits ranging 
from easy innovations, high scalability, simplified network management, robust 
fault tolerance, and infrastructure saving to many more. Thus, SDN emergence 
has resulted in reconsidering our viewpoints regarding network architecture and 
design. 
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